home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 182 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  5.7 KB

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: jbuck@Synopsys.COM (Joe Buck)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Give operator. a chance
  5. Date: 26 Jan 1996 00:05:36 GMT
  6. Organization: Synopsys Inc., Mountain View, CA 94043-4033
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4e90k4$gqr@hermes.synopsys.com>
  9. References: <3102AD11.1663@et.se> <4e0nc3$4dp@engnews1.eng.sun.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Content-Type: text
  12. X-Nntp-Posting-Host: deerslayer.synopsys.com
  13. Content-Length: 5058
  14. X-Lines: 93
  15. Originator: clamage@taumet
  16.  
  17. clamage@Eng.Sun.COM writes:
  18. >It's hard for me to imagine that anyone could come up with new arguments
  19. >in favor of operator.() that also answer the objections to it. If you think
  20. >you can do so, go ahead, but do yourself and everyone else a favor and
  21. >acquaint yourself with the discussion that has already occurred. Note
  22. >especially the arguments in the ARM and D&E against "operator dot".
  23.  
  24. Since I want a language standard soon, I'll live without operator dot.
  25. But I will object to attempts to rewrite history.
  26.  
  27. Please note that in D&E Stroustrup does not argue against overloaded
  28. operator dot, but rather against specific proposals.  Unfortunately,
  29. Stroustrup's arguments against specific overloaded operator dot proposals
  30. are rather embarrassing for him, not up to his usual standard of skillful
  31. writing.  But if you wish, I will answer them.
  32.  
  33. In D&E, section 11.5.2, he objects that obj.m already has a meaning,
  34. and that overloading operator. would thus make the language mutable,
  35. but he admits that the rule is broken for operator= and operator&.
  36.  
  37. The second objection, that overloading both operator. and operator->
  38. would cause problems, is also easily dismissed.  The answer is simple:
  39. "don't do that".  One overloads operator. to make a class that has
  40. reference semantics.  One overloads operator-> to make a class that
  41. has pointer semantics.  It would be bad design to make an object that
  42. works like both a pointer and a reference, so the fact that such classes
  43. are difficult to write because you can't get to their members is not an
  44. issue.
  45.  
  46. Stroustrup then comes to the Adcock proposal.  He points out its benefits
  47. in implementing delegation (a "handle" class or a "proxy" class).  He
  48. then objects that overloading operator. does not do the complete job
  49. (he says "doesn't have the right effect") because there are cases
  50. where the dot is not mentioned (when overloaded operators are used)
  51. so that there is still the need to write forwarding functions for
  52. them.  He states "this is clearly tedious".  But the tedium is
  53. substantially reduced with respect to what it is now (no forwarding
  54. functions for normal member functions, only overloaded operators).
  55. Since many classes don't overload *any* operators, this tedium reduces
  56. to zero.
  57.  
  58. Note that the example he chooses stacks the deck against the Adcock
  59. proposal, in that the proxy class has one member function and two
  60. overloaded operators, meaning that overloaded operator dot saves only
  61. one forwarding function.  But I have several examples in the project
  62. I am currently working on where there are eight to twelve functions
  63. to be forwarded and no overloaded operators.  I need to write inline
  64. functions for every last one of them, and all changes have to be
  65. done in two places.
  66.  
  67. Stroustrup then describes a *new* proposal in which operator. has the
  68. magic behavior of also forwarding overloaded operators.  There was
  69. evidently disagreement in the committee over which is better (I think the
  70. Adcock proposal is cleaner myself, though I could live with this one).
  71. Not mentioned here, but mentioned in some comp.std.c++ discussions,
  72. is that people objected to that one because of the "surprise factor"
  73. (I wrote no dot, why is operator. being called?).
  74.  
  75. He next objects that overloading operator. breaks the equivalence of
  76. a.m and (&a)->m.  Sorry, Dr. Stroustrup, there is no such equivalence,
  77. thanks to overloaded operator & .  The symmetry was broken by the
  78. creation of "smart pointers".  Symmetry can be restored by dropping
  79. operator& and operator->, or by adding operator dot.
  80.  
  81. He then points out that you could restore this symmetry when overloading
  82. operator. by generating automatic overloads operator& and operator-> to
  83. match operator. and immediately points out that this would cause problems.
  84. But this is a straw man.  Never before in C++ did overloading one operator
  85. change others.  Overloading += doesn't create a matching overload for + to
  86. force a consistent meaning for addition.  Why raise hoops for
  87. extensions that the core language cannot meet?  Why make the language
  88. inconsistent in this way?
  89.  
  90. "We are thus left in a quandry: we can either maintain the a.m and
  91. (&a)->m equivalence or have access to members of the smart reference,
  92. but not both".  False.  There is already operator&.  There is no
  93. guaranteed equivalent in the language of a.m and (&a)->m today,
  94. with or without any extensions.  We can exploit the broken symmetry and
  95. allow access to members of the smart reference with (&a)->m.
  96.  
  97. Stroustrup proposes that operator. only forward to the resulting class
  98. for a.m if the object itself doesn't have a member m.  I dislike that
  99. approach; it is unnecessary since (&a)->m accesses it, and since
  100. the class is going to present itself as a disguised reference object
  101. in any case, only private code is going to mess around with the object's
  102. own members.  In member functions, one would merely write "m".
  103.  
  104.  
  105. -- 
  106. -- Joe Buck     <jbuck@synopsys.com>    (not speaking for Synopsys, Inc)
  107.  
  108. Work for something because it is good,
  109. not just because it stands a chance to succeed.       -- Vaclav Havel
  110.  
  111. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  112.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  113.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  114.  
  115.